3GPP is currently in the process of defining the core specifications for a Radio Link Control (RLC) protocol layer responsible for reliably transferring data packets using protocol data units (PDUs). For LTE/EUTRA, a baseline status PDU format has been agreed upon consisting of a cumulative ACK_SN and/or a list of NACK_SNs as illustrated in prior art FIG. 4. Under the current baseline status PDU format, the sender of a data PDU assumes by default that a PDU/PDU segment with SN smaller than ACK_SN is received successfully if it is not NACKed explicitly through the list of NACK_SNs. However, if the size of the status PDU prepared according to the baseline format is larger than the available bandwidth allocated by Medium Access Control (MAC), the sender of the data PDU may clear the transmission buffer prematurely, which is problematic.
The scenario where the entire status PDU is greater than the available resources is more likely to occur when the Medium Access Control (MAC) Transmission Block (TB) is relatively small. In the baseline status PDU format of prior art FIG. 4, the D/C, CPT, ACK_SN, and E1 fields have taken 15 bits, and these fields are present in every status PDU. For the remaining list of NACKs, a PDU NACK consumes 12 bits (NACK_SN, E1 and E2), and a PDU segment NACK consumes 42 bits (NACK_SN, E1, E2, SOstart and SOend).
The RLC status PDU is prepared when a transmission opportunity is informed by MAC. Since the size of the prepared RLC status PDU is independent of the MAC allocated resource, it is possible that the original status PDU is larger than the available bandwidth, especially when the channel condition is poor and the sender has to re-segment PDUs during retransmission, which leads to NACKing PDU segments.
For a MAC TB size of 88 bits, which is the smallest size, only 72 bits are available for RLC PDU(s) because the MAC header uses 2 bytes. When transmitting a status PDU, after using 15 bits for the D/C, CPT, ACK_SN, E1 fields, the remaining (72−15) 57 bits are only sufficient to NACK 1 PDU segment plus 1 PDU, or up to 4 PDUs. For a 104 bit MAC TB, which is next to the smallest TB size, 88 bits are available for RLC PDU. These bits can only NACK 1 PDU segment plus 2 PDUs, or up to 6 PDUs. Similarly, for a 136 bit MAC TB, 120 bits are available for RLC PDU. These bits can only NACK 2 PDU segments plus 1 PDU or 1 PDU segment plus 5 PDUs or up to 8 PDUs.
Thus when the original status PDU is larger than the available bandwidth, the receiver of the status PDU may interpret the status report incorrectly. For example, if the transmitter sends an RLC PDU of sequence number (SN) 1 through 13, the PDUs of SNs {1, 3, 5, 6, 7, 9, 11, 12} are missing at the receiver side, as depicted in FIG. 2. In 3GPP TS 36.322 v8.0.0, “Radio Link Control (RLC) protocol specification (Release 8)”, ACK_SN must be set as 13 because VR(MS)=13. If only SN=1, 3, 5, 6, 7 and 9 are included in the NACKs list of the status report, the data PDU sender will assume that SN=11 and 12 have been received correctly and clear the buffer accordingly. Actually NACKing any 6 out of the missing 8 PDUs will implicitly acknowledge the receipt of the other two remaining PDUs.
The example above considers only PDU NACKs to simplify the description. The problem is more likely to involve PDU segment NACKs, because they use more bits in a report. According to the baseline status PDU format, one cumulative ACK SN and eight NACK SNs should be included in the status PDU. However, if the available MAC resource is only able to accommodate 6 NACK SNs, as is the case if the next to smallest MAC TB is used (104 bits), the original status PDU must be truncated to fit into the MAC allocation.
The various aspects, features and advantages of the disclosure will become more fully apparent to those having ordinary skill in the art upon a careful consideration of the following Detailed Description thereof with the accompanying drawings described below. The drawings may have been simplified for clarity and are not necessarily drawn to scale.